Skip to content

Conversation

DaveHanns
Copy link

@DaveHanns DaveHanns commented Oct 2, 2025

Changes related to move of restartOnError from Actor's top level to its run options.

Core: https://github.com/apify/apify-core/pull/23381
Worker: https://github.com/apify/apify-worker/pull/1515
Shared: apify/apify-shared-js#546
JS Client: apify/apify-client-js#760
Docs: apify/apify-docs#1965

@DaveHanns
Copy link
Author

DaveHanns commented Oct 3, 2025

Pinging @valekjo and @gippy for reference as they are reviewing the rest of related PRs.

Copy link
Member

@fnesveda fnesveda left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't someone from tooling team who handles Python development be assigned for review too, instead of 3 platform devs?

@DaveHanns DaveHanns marked this pull request as ready for review October 3, 2025 12:23
@DaveHanns DaveHanns requested review from janbuchar and removed request for gippy and valekjo October 3, 2025 12:27
@DaveHanns
Copy link
Author

Shouldn't someone from tooling team who handles Python development be assigned for review too, instead of 3 platform devs?

Yep, added @janbuchar.

@janbuchar
Copy link
Contributor

Shouldn't this be a fix: instead of a feat:?

@vdusek vdusek changed the title feat: move restart on error Actor option to Run options fix: move restart on error Actor option to Run options Oct 7, 2025
@janbuchar janbuchar added the adhoc Ad-hoc unplanned task added during the sprint. label Oct 8, 2025
max_items: int | None = None,
memory_mbytes: int | None = None,
timeout_secs: int | None = None,
restart_on_error: bool | None = None,
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: @janbuchar, is this a breaking change (changing the order of the parameters) ? I'm not sure about the exact intricacies of the Python argument ordering.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, technically it is. But:

  1. Nobody in their right mind would call this with positional (non-keyword) arguments. In fact, the entire signature of the function should probably be keyword-only, but that's breaking
  2. While it is not de facto private, it probably should be

That considered, is it a problem to just move the parameter down?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I wasn't specific enough and didn't choose the best example. Similar changes are present throughout this and other files in public function. Please, see the last commit.

See for instance start. Same question there.

The positioning can be changed, but I would rather keep it near other similar options.
What do you think ? In other languages, it would definitely be a BC, but I'm not sure about the Python.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image If the signature has this, any parameters behind the asterisk can go in any order, no BC break. What the thing means is "everything after the asterisk must be passed with a keyword (`foo(..., bar=42)`)", so the order doesn't matter.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, thanks.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, if there's no asterisk in the list of args, I'd just add a new argument at the end, just to be safe.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. Only such occurrence was in get_task_representation in the task.py.
Moved to the end of args list.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Im getting FBT001 Boolean-typed positional argument in function definition linting error.
Would adding asterix in the list help?

def get_task_representation(
    actor_id: str | None = None,
    name: str | None = None,
    task_input: dict | None = None,
    build: str | None = None,
    max_items: int | None = None,
    memory_mbytes: int | None = None,
    timeout_secs: int | None = None,
    title: str | None = None,
    actor_standby_desired_requests_per_actor_run: int | None = None,
    actor_standby_max_requests_per_actor_run: int | None = None,
    actor_standby_idle_timeout_secs: int | None = None,
    actor_standby_build: str | None = None,
    actor_standby_memory_mbytes: int | None = None,
    *,
    restart_on_error: bool | None = None,
) -> dict:

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, Asterix should be able to help. The lint rule exists because free-floating boolean arguments are confusing (foo(True, True, False, True)).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@DaveHanns DaveHanns requested a review from janbuchar October 9, 2025 07:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

adhoc Ad-hoc unplanned task added during the sprint. t-console Issues with this label are in the ownership of the console team.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants